# RFC 768 (User Datagram Protocol, UDP)

**RFC 768**은 인터넷 프로토콜 스위트의 전송 계층(Transport Layer)에서 사용되는 **UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)**의 사양을 정의한 표준 문서입니다.

*   **원문 링크:** [RFC 768 - User Datagram Protocol](https://datatracker.ietf.org/doc/html/rfc768)

---

## 1. 개요
UDP는 OSI 7계층 모델의 전송 계층에서 동작하는 단순한 프로토콜로, 애플리케이션 프로세스 간의 메시지 전송을 위해 설계되었습니다. TCP(Transmission Control Protocol)와 달리 연결 설정 과정 없이 데이터를 전송하는 **데이터그램(Datagram)** 방식을 사용합니다. 여기서 데이터그램이란 독립적인 경로를 통해 전송되는 하나의 데이터 단위를 의미합니다.

UDP의 주된 목적은 전송 오버헤드를 최소화하여 빠른 데이터 전송 속도를 확보하는 것이며, 신뢰성보다는 효율성과 실시간성이 중요한 서비스에 최적화되어 있습니다. 특히 RFC 768은 **1980년에 발표된 매우 오래된 표준**임에도 불구하고, 그 설계가 매우 단순하고 강력하여 이후 거의 수정 없이 유지되고 있다는 점이 특징입니다.

## 2. UDP의 주요 특징
UDP는 최소한의 기능만을 제공하는 '경량 프로토콜'입니다. 주요 특징은 다음과 같습니다.

*   **비연결성 (Connectionless):** 데이터를 보내기 전 송신측과 수신측 사이에 연결을 설정하는 과정(Handshake)이 없습니다. 따라서 연결 유지 비용이 발생하지 않습니다.
*   **비신뢰성 (Unreliable):** 패킷의 도착 여부를 확인하지 않으며, 손실된 패킷에 대한 재전송 요청을 수행하지 않습니다. 또한 패킷이 송신 순서대로 도착하는 것을 보장하지 않습니다.
*   **낮은 오버헤드:** 헤더 크기가 매우 작고 흐름 제어(Flow Control)나 혼잡 제어(Congestion Control) 메커니즘이 없어 CPU 및 메모리 자원 소모가 적습니다.
*   **단방향/다방향 전송:** 1:1 전송뿐만 아니라 유니캐스트, 멀티캐스트, 브로드캐스트 전송을 모두 지원합니다.

### [표] TCP vs UDP 비교

| 구분 | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
| :--- | :--- | :--- |
| **연결 방식** | 연결 지향형 (Connection-oriented) | 비연결형 (Connectionless) |
| **신뢰성** | 높음 (데이터 전송 보장, 순서 보장) | 낮음 (데이터 손실 가능성, 순서 무관) |
| **전송 속도** | 상대적으로 느림 (제어 과정 필요) | 매우 빠름 (즉시 전송) |
| **데이터 단위** | 세그먼트 (Segment) | 데이터그램 (Datagram) |
| **흐름/혼잡 제어** | 지원함 | 지원하지 않음 |
| **헤더 크기** | 20 ~ 60 바이트 | 8 바이트 (고정) |

## 3. 패킷 구조 (Packet Format)
RFC 768에서 정의한 UDP 헤더는 매우 단순하며, 총 8바이트(64비트)의 고정 크기를 가집니다.

### 헤더 구조 다이어그램
```text
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port              |       Destination Port     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length                  |           Checksum         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                                |
+                           Data                                 +
|                                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

### 헤더 필드 상세 명세

| 필드명 | 크기 (Bit) | 설명 |
| :--- | :---: | :--- |
| **Source Port** | 16 | 송신자의 포트 번호 (**0 ~ 65535 범위의 16비트 정수**). 응답을 받을 때 사용되며, 필요 없는 경우 0으로 설정 가능함. |
| **Destination Port** | 16 | 수신자의 포트 번호 (**0 ~ 65535 범위의 16비트 정수**). 데이터를 전달할 대상 애플리케이션을 식별함. |
| **Length** | 16 | **UDP 데이터그램의 총 길이** (UDP 헤더와 데이터를 합친 길이, 단위: 바이트). IP 헤더 길이는 포함되지 않으며, 데이터가 없는 경우 **최소값은 8**임. |
| **Checksum** | 16 | 헤더와 데이터의 무결성을 검증하기 위한 값. **IPv4에서는 선택 사항**이나, **IPv6에서는 필수**로 구현되어야 함. |

## 4. 동작 원리 및 프로세스

### 데이터 전송 흐름
1. **캡슐화:** 애플리케이션 계층에서 생성된 데이터에 8바이트의 UDP 헤더가 붙어 UDP 데이터그램이 생성됩니다.
2. **전송:** IP 계층으로 전달되어 목적지 IP 주소를 기반으로 네트워크를 통해 전송됩니다.
3. **수신:** 수신측 호스트는 목적지 포트 번호를 확인하여 해당 포트를 열고 대기 중인 프로세스에 데이터를 전달합니다.

### 체크섬(Checksum) 계산 방식
UDP의 체크섬은 데이터 전송 중 발생한 비트 오류를 검출하기 위해 사용됩니다. 상세 계산 절차는 다음과 같습니다.

1. **가상 헤더(Pseudo Header) 생성:** IP 주소(송신/수신), 프로토콜 번호(UDP=17), UDP 길이 정보를 포함하는 가상의 헤더를 생성합니다. 이는 IP 계층의 정보가 올바르게 전달되었는지 함께 검증하기 위함입니다.
2. **16비트 단위 합산:** 가상 헤더, UDP 헤더, 그리고 실제 데이터를 모두 16비트 단위의 워드로 나누어 모두 더합니다.
3. **캐리(Carry) 처리:** 더하는 과정에서 16비트를 초과하여 발생한 올림수(Carry)는 다시 결과값의 최하위 비트에 더해줍니다(One's Complement Sum).
4. **보수 취하기:** 최종 합산 결과에 대해 1의 보수(Bitwise NOT)를 취하여 체크섬 필드에 기록합니다.
5. **검증:** 수신측에서 가상 헤더를 포함하여 체크섬 필드까지 모두 합산했을 때, 결과가 **0xFFFF(또는 0)**가 되면 오류가 없는 것으로 판단합니다.

## 5. 주요 활용 사례
UDP는 신뢰성보다 **속도**와 **실시간성**이 우선시되는 환경에서 주로 사용됩니다.

*   **실시간 스트리밍 및 VoIP:** 유튜브 라이브, Zoom, 인터넷 전화 등. 일부 패킷이 손실되어 화면이 잠시 깨지거나 소리가 튀더라도, 전체 흐름이 끊기지 않고 **실시간으로 전달**되는 것이 더 중요하기 때문입니다.
*   **온라인 게임:** FPS나 MOBA 장르의 게임. 플레이어의 위치 정보 등은 매우 빈번하게 업데이트되므로, 이전 패킷의 재전송보다는 **최신 패킷을 빠르게 받는 것**이 중요합니다.
*   **DNS (Domain Name System):** 도메인 이름을 IP 주소로 변환하는 쿼리 서비스. 요청과 응답이 매우 짧고 단순하며, 패킷 손실 시 클라이언트가 다시 요청하면 되므로 **오버헤드 최소화**가 가능합니다.
*   **DHCP (Dynamic Host Configuration Protocol):** IP 주소를 자동으로 할당받는 과정. 초기 연결 단계에서는 상대방의 IP를 모르기 때문에 **브로드캐스트**가 가능한 UDP를 사용합니다.

## 6. 한계 및 보완책

### 태생적 한계
*   **패킷 손실:** 네트워크 혼잡 시 패킷이 버려져도 송신자는 이를 알 수 없습니다.
*   **순서 바뀜 (Out-of-order):** 서로 다른 경로로 전송된 패킷들이 수신측에 도착하는 순서가 송신 순서와 다를 수 있습니다.
*   **중복 수신:** 동일한 패킷이 네트워크 상에서 복제되어 여러 번 도착할 수 있습니다.

### 보완 방법
이러한 한계를 극복하기 위해 개발자는 **애플리케이션 계층(Application Layer)**에서 직접 신뢰성 메커니즘을 구현합니다.

*   **시퀀스 번호 부여:** 데이터에 순서 번호를 붙여 수신측에서 순서를 재조합합니다.
*   **ACK/NACK 구현:** 중요한 데이터의 경우 수신 확인 메시지를 주고받도록 설계합니다.
*   **QUIC (Quick UDP Internet Connections):** 구글에서 개발한 프로토콜로, UDP의 빠른 속도를 유지하면서 TCP의 신뢰성(흐름 제어, 패킷 재전송)을 애플리케이션 계층에서 구현한 사례입니다. 이는 현재 HTTP/3의 기반 프로토콜로 표준화되었습니다.